Fix auth_app for modern Taiga versions (#227) - #229
Conversation
8b25288 to
5a4f5a8
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #229 +/- ##
==========================================
+ Coverage 96.47% 97.07% +0.60%
==========================================
Files 8 8
Lines 936 923 -13
Branches 67 64 -3
==========================================
- Hits 903 896 -7
+ Misses 19 16 -3
+ Partials 14 11 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@heck-gd Thanks for this! I'll ping @yakky to have a look at this as soon as possibile, I added a small comment because I'm not entirely sure about what should |
|
Hi, any news on getting this merged? |
yakky
left a comment
yakky
left a comment
There was a problem hiding this comment.
Due to the incompatible signature of auth_app we should release this with a major version bump and documenting the breaking change in the documentation
- Reclassify the changelog fragment for #227 as a breaking change, removal type, instead of a bugfix, since auth_app's signature and return value both changed. - Document the new auth_app flow in docs/usage.rst. - Add coverage for the 200-response-without-token error branch. - Version bump to 2.0.0 is left to the release process, per review on #229. Co-authored-by: Melissa Eckardt <melissa.eckardt@gdata-adan.de>
|
Thanks again for the fix and for the patience while this sat! I rebased your commit onto current master and packaged it as a breaking change (major version bump left to the release process, changelog fragment reclassified, docs added, missing-token branch covered by a test) in #269, which supersedes this PR. Your commit and AUTHORS entry are preserved as-is — closing this in favor of #269. |
4 participants
Description
auth_app()to (only) work with Taiga 3.1.0+ (released in 2016).auth()- rather, it only works once per token because the Taiga backend invalidates theauth_codeduring the request. From what I can tell, applications are supposed to store and re-use the token. It doesn't have an expiration, unlike Bearer tokens.References
Fixes #227
Due to removal of dependency, also fixes #189
Checklist
inv lintchangesfile included (see docs)